Commercial line-of-business applications are commonly customized as part of their deployment to fit them to the needs of that particular business. Additional third-party software is also employed to handle particular processes.
A common customization is to add new data fields to existing tables. Developers accessing that data are typically provided an application programming interface (API) with classes to represent each abstract entity in the application. For example, an application may have a Vendor class with several properties representing its name, address and other relevant information. Such an API provides conveniences to the developer such as allowing the display of the properties with a class viewer, allowing the compiler to verify that accessed data elements are present (rather than discovering such issues when the application is run) and simplifying the authoring of logic against the data.
Many commercial applications vendors publish the source code for their applications, enabling customizing developers to modify the source to add fields and accompanying business logic. This has the disadvantage that new releases of the software often have changes that are made to the same area of the code that the customizer modified. Installing the new release requires reapplying the changes, a real issue for customers and customizers alike.
Another issue is that developers are required to use the classes produced for them by the original application developer. While such classes are often helpful, often they are not. Different developers typically need to use data in different scenarios, and the class provided by the application developer may not be optimized for that scenario. Consider two developers who are working with Order data in very different ways. The first developer is writing an order creation form that must validate all data entered so that the order can be processed without delay. The second developer is writing an application that talks to the business system through a web service and requests that it create an order. The Order class used to implement the data entry form isn't a good fit for the web service scenario because it is (1) interactive rather than batch, (2) provides more validation than is needed in that case (as the order will need to be verified later anyway) and (3) exposes internal policy to web service users. Exposing internal policy is problematic both because it may reveal operational details about the company and because policies may change.
A third issue that both the customizer and the original application developer face is the need to interact with more of the application data than is strictly necessary for the functionality they're producing. This is negative in a more subtle way, because it introduces unnecessary coupling between two parts of the application and makes it difficult to know if a dependency on a particular data element is actually present. Such unnecessary coupling has proven to make an application more complex, which makes maintenance more complicated over time.
Thus, needed are processes and a system that addresses the shortcomings of the prior art.